default exportを避ける

ESM関連のこれの問題ってまだ解決されてないのかな

こういう書き方をしないといけないやつ

code:ts

import foo from "foo";

foo.default();

code:ts

const foo = await import("foo");

foo.default.default();

default exportすると、importした側が自由に名前をつけられる

逆に言えばexportする側は、命名を強制できない

従って、export側で、実装の修正に伴ってrenameした場合に、import側でそのrenameを検知できない

その結果、実装と名前が乖離した状態になってしまう

手動で見て回ってrenameしていけば良いが手間なので、それなら最初からnamed exportした方が楽

named exportでもasを使えば同じ問題は起きる

ただ、問題の度合いが全然異なると思うmrsekut.icon

import {hoge as piyo} from '..'と書いた場合は、export側の意図であるhogeも一応import側に表示される

import * as Hoge from '..'と書いた場合は表示されないが、

Hoge.hoge()と利用する時に表示されるので問題ない

利用側に命名の余地を残すかどうかという話は、

Reactでのhooksの返り値を[hoge,piyo]にするのか

{hoge, piyo}にするのか、

という話とも似ている

補完が効くので嬉しい

importする際に、named exportしてるものが対象になる

いや、これは別にdefault exportでも効くねmrsekut.icon

https://i.gyazo.com/e7002078ab7d6d6c57813c6a999e9bde.gif

ただし、anonymous default exportなら無理

code:ts

export default () => 2;

それはそうmrsekut.icon

なので基本的に、わざわざdefault exportを使う必要はないと思う

しかし、使用しているframeworkの都合でそれを使わざるを得ないことは多々ある

でもまあそれは、自分でimportする対象でないことが多いので特に問題にならない

Next.js 13のapp/内でのComponent定義とか

参考

Avoid Export Default - TypeScript Deep Dive 日本語版

default exportの問題が列挙されている

なぜ default export を使うべきではないのか？ - LINE ENGINEERING

むしろ「default exportを使うべき」という意見

named exportは有害だと考えられます

この記事では「1つのmoduleが公開するものは1つであるべき」という主張が前提にある

実際、ReactのComponentなんかは1ファイルに1つのみ定義することも多い

これが常にやるのは実際難しそう

この前提があるなら、default exportしか使わなくても問題はなさそう

ただ、この前提があるならnamed exportを否定する理由にはならなくないか

従属物を入れる時にpropertyを生やすのは気持ち悪いな ref

これをやるならimport * as Hoge from '..'でも同じことができる

だから、default exportを使う理由にはならない

アンサー: named exportは有害なのか - uhyo/blog

上記記事に対するアンサー

そうだね、という感じの内容